COMMENT ⊗   VALID 00004 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00003 00002	%elepha[s89,jmc]		Elephant 2000
C00004 00003	\noindent Abstract: Elephant 2000 is a vehicle for some ideas about
C00008 00004	(Because the full paper is an incomplete draft, only the
C00023 ENDMK
C⊗;
%elepha[s89,jmc]		Elephant 2000
\input memo.tex[let,jmc]
\centerline{INCOMPLETE PRELIMINARY DRAFT of \jmcdate}
\bigskip
\rightline{\vbox{\it
  \hbox{I meant what I said, and I said what I meant.}
  \hbox{An elephant's faithful, one hundred percent!}
  \smallskip
  \hbox{\rm moreover,}
  \smallskip
  \hbox{An elephant never forgets!}}}
\bigskip
\title{Elephant 2000: A Programming Language Based on Speech Acts}


\medskip
\noindent Abstract: Elephant 2000 is a vehicle for some ideas about
programming language features.  We expect these features to be
valuable in writing and verifying programs that interact with
people (e.g. transaction processing) or interact with programs belonging
to other organizations (e.g. electronic data interchange)
\hfill\break 1. Communication inputs and outputs are in an I-O
language whose sentences are meaningful speech acts approximately
in the sense of philosophers and linguists.  These include
questions, answers, offers, acceptances, declinations, requests,
permissions and promises.
\hfill\break 2. The correctness of programs is partially defined in
terms of proper performance of the speech acts.  Answers should
be truthful, and promises should be kept.  Sentences of logic expressing
these forms of correctness can be generated automatically
from the form of the program.
\hfill\break 3. Elephant source programs may not need data
structures, because they can refer directly to the past.  Thus a
program can say that an airline passenger has a reservation if he
has made one and hasn't cancelled it.
\hfill\break 4. Elephant programs themselves will be represented as
sentences of logic.  Their properties follow from this
representation without an intervening theory of programming or
anything like Hoare axioms.
\hfill\break 5. Elephant programs that interact non-trivially with
the outside world can have both {\it illocutionary} and {\it perlocutionary}
specifications, i.e. behavioral specifications relating inputs and outputs,
and specifications concerning what they accomplish in the world.

The present draft is very incomplete, and not all the above
features are presented or even worked out.  However, most of the goals
are explained, and the author welcomes help and advice in achieving them.
Since the final version will probably be different in many ways, readers
with a casual interest should skip this draft.
\eject
(Because the full paper is an incomplete draft, only the
abstract and introduction are included in this handout).

\section{Introduction}

	This paper proposes several new features for programming
languages.  As a vehicle we introduce Elephant 2000, a language
that would embody them.  In the present draft, these features are
not fully embodied in the program examples.

	1. Elephant programs communicate with people and other
programs in sentences of the Elephant I-O language which have
meanings partially determined by the Elephant language and
partially implicit in the program itself.  Thus Elephant input
and output includes and the I-O language distinguishes {\it
requests}, {\it questions}, {\it offers}, {\it acceptances of
offers}, {\it permissions} as well as {\it answers to questions}
and other assertions of fact.  Its outputs also include
statements of {\it commitment} analogous to promises.  Some
communications between parts of a program may also usefully be
treated as speech acts.

	Non-communication observations and actions
may have meanings defined in the Elephant language.

	2. Some of the conditions for correctness of an Elephant
program are defined in terms of the meaning of the inputs and
outputs.  We can ask whether an Elephant program fulfilled a
request, answered a question truthfully, accepted
an offer or fulfilled a commitment. We can also ask whether the
program has authority to do what it does.  We call such
correctness conditions {\it intrinsic}, because the text of the
program determines them.  Expressing these intrinsic correctness
conditions as sentences of logic requires a formal theory of what
it means to fullfil a commitment, etc.  This theory doesn't have
to correspond exactly to human behavior; we only need analogs
useful for program correctness.  
%
For example, when a program
``promises'' someone to do something, it needn't believe
that fulfillment of the promise will do its recipient some
good.  Indeed some programs that promise might not have any
beliefs at all.
%
We expect to be able to generate the intrinsic correctness sentences
 automatically from the text of the program.  For example,
given the text of the program that designates certain outputs
as answers to questions, there is a logical sentence corresponding
to the assertion that the answers are truthful.

	3. Elephant programs do not require data structures,
because program statements can refer directly to past events and
states.  An Elephant interpreter keeps a history list of past
events, and an Elephant compiler constructs whatever data
structures in the object language are needed to remember the
information needed for compiled program to behave as specified in
the Elephant source program.  It isn't yet clear whether it will be
convenient to omit data structures completely from the language.

	4. An Elephant program is itself a logical sentence
(or perhaps a syntactic sugaring of a logical sentence).  The
correctness properties of the program are logical consequences
of this sentence and a theory of the domain in which the
program acts.  Thus no logic of programs is needed.  Any sugaring
should be reversible by a statement-by-statement syntactic
transformation.

	5. Requests, permissions and promises such as those we
want Elephant programs to perform are called {\it speech acts} by
philosophers and linguists.  Their idea is that certain sentences
don't have only a declarative significance but are primarily
actions.  A paradigmatic example is a promise, whose utterance
creates an {\it obligation} to fulfill it and is therefore not
merely a statement of intention to do something.  For many
purposes, we can bypass the the philosophical complexities of
{\it obligation} by considering only whether a program {\it does}
fulfill its promises, not worrying about whether it is obliged
to.

	Using the customary terminology, some of the outputs of
Elephant programs are {\it performative} sentences, commonly
referred to just as {\it performatives}.  Indeed Elephant 2000
started with the idea of making programs use performatives.
However, as the ideas developed, it seemed useful to deviate from
the notions of speech act discussed by J. L. Austin (1962) and
John Searle (1969).  Thinking about speech acts from the {\it
design standpoint} of Daniel Dennett (1971) leads to a view of
them different from the conventional one.  We now refer to {\it
abstract performatives} which include purely internal actions
such as {\it commitments} not necessarily expressed in output,
but on whose fulfillment the correctness of the program depends.
Taking the design stance in the concrete way needed to allow
programs to use speech acts leads to new views on the
philosophical problems that speech acts pose.

	Notice that we don't need to apply moral terms like {\it
honest}, {\it obedient} or {\it faithful} to the program, and we
won't in this paper.  However, we can incorporate whatever abstract
analogs of these notions we find useful.  The philosophical
investigations have resulted in ideas useful for our purposes.
This is partly because programs belonging to one organization
that interact with those belonging to other organizations
will have to perform what amounts to speech acts, and the
specifications of these programs that have to be verified
often correspond to what Austin calls the {\it happy} performance
of the speech acts.

	(McCarthy 1979) discusses conditions under which
computer programs may be ascribed beliefs, desires, intentions
and other mental qualities.  It turns out that some specifications
require ascription of beliefs, etc. for their proper statement,
and others do not.

	This article is exploratory, and we are not yet prepared
to argue that every up-to-date programming language of the year
2000 will include {\it abstract performatives}.  We hope that
programs using performatives will be easier to write, understand,
debug, modify and (above all) verify.
 Having a standard vocabulary of requests,
commitments, etc. will help.

	Allowing direct reference to the
past may also permit easier modification, because the program can
refer to past events, e.g. inputs and outputs, directly rather
than via data structures whose design has to be studied and
understood.  Since referring directly to past events is
characteristic of natural languages, we expect it to prove useful
in programming languages.

	6. The theory of speech acts distinguishes between
 {\it illocutionary}
 acts, such as telling someone something, and
 {\it perlocutionary}
 acts, such as convincing him of it.
The distinction between illocutionary and perlocutionary
can be applied to speech inputs as well as outputs.  Thus there
is an input distinction between {\it hearing that} and {\it learning that}
analogous to the output
distinction between telling and convincing.

	Procedures for human execution often specify perlocutionary
acts.  For example, a teacher might be told, ``Have your students
take the test on Wednesday''.  However, including
perlocutionary acts in programs is appropriate only if the
program has good enough resources for accomplishing goals to make
it reasonable to put the goal in the program rather than actions
that the programmer believes will achieve it.  One would
therefore expect perlocutionary statements mainly in programs
exhibiting intentionality, e.g. having beliefs, and involving
some level of artificial intelligence.

	Even without putting perlocutionary acts in the program itself, it is
worthwhile to consider both illocutionary and
perlocutionary {\it specifications}
 for programs.
For example, an air traffic control
program may be specified in terms of the relations between its
inputs and its outputs.  This is an illocutionary specification.
Its verification involves only the semantics of the programming
language.
  However, our ultimate goal is to specify and verify that
the program prevents airplanes from
colliding, and this is a perlocutionary specification.  Proving that
a program meets perlocutionary specifications must be based on
assumptions about the world, the information it makes available
to the program and the effects of the program's actions as well
on facts about the program itself.

	It will usually be
worthwhile to formulate both illocutionary and
perlocutionary specifications for the same
program and to relate them.  Thus
an argument based on an axiomatic theory of the relevant aspects of
 the world may be used to
show that a program meeting certain illocutionary specifications
will also meet certain perlocutionary specifications.
The problem of justifying such axiomatic theories is like that of
justifying other formalized theories of the physical world in
applied mathematics.

	Anyone who doesn't like the terms {\it illocutionary} and
{\it perlocutionary} is invited to refer to {\it behavioral}
or {\it input-output}
specifications and {\it accomplishment} specifications.

	7. The most obvious applications of Elephant are in programs
that do transaction processing and refer to databases in more
general ways than just answering queries and making updates.
Abstract performatives will also be important for programs
involved in business communication with programs belonging
to other organizations.  (McCarthy 1982) describes a ``Common
Business Communication Language''.
\vfill\end